(navigation image)
Home American Libraries | Canadian Libraries | Universal Library | Community Texts | Project Gutenberg | Children's Library | Biodiversity Heritage Library | Additional Collections
Search: Advanced Search
Anonymous User (login or join us)
Upload
See other formats

Full text of "PCMania 56"

SUPLEMENTO MENSUAL DEDICADO A LA IMAGED SINTETICA 




Vimero 6 



La Portada 



Programacion 
escenica de 
desastres 
virtuales 

Como... 
Preparar 
el acabado de 
superficies en 
Imagine 



Taller Virtual 



La atmosfera 
en POV 3.0 



Foro del lector 



Piezas 
parajuegos 
y batallas 
virtuales 

pctfDanfa 




I II I 




mi 



$ 



* ^LComo. 



»I# 



/ose Manuel Muhoz 



Preparar el acabado de 



El numero anterior fue 
el segundo dedicado a 
Imagine. Hasta ahora 
hemos estudiado los 
Editores de Formas, 
Detalles, Escenas y 
Proyectos. En 
conjunto lo ya visto es 
suficiente para 
permitir al lector 
acometer proyectos 
de cierta envergadura, 
aunque quedan 
muchas cosas por 
tratar. Por ejemplo, 
^como crear acabados 
pianos en los objetos?, 
6c6mo aplicar bitmaps?. . . 




1 acabado es uno de 

Elos apartados mas 
importantes al gene- 
rar imageries sinteti- 
cas. Empezaremos 
viendo cdrao crear 
acabados pianos o redondeados. Luego 
repasaremos el Gestor de Atributos y 
concluiremos con el tenia de la aplicacion 
de bitmaps y la generation de sombras. 



Superficies redondeadas y 
alisadas 

Existen muchos algoritmos de som- 
breado de superficies. Imagine, por de- 
fecto, emplea el sombreado Phong con 
el cual los objetos toman una apariencia 
redondeada ante nuestra vista, a pesar de 
que, realmente, estan construidos me- 
diante una malla de caras planas o face- 
tadas. Con este algoritmo se calcula el 



2 Rendermania 



Todo los ficheros de inclusion y los 
ejemplos podeis encontrarlos en el 
| directorio PCMANIA\RENDER56 

del CD-Rom. 

La version completa de Imagine 3.0, 
junto con las texturas, se incluye, de 
nuevo, en el CD-Rom de este numero. 



superficies en Imagine 



color adecuado para cada punto de la su- 
perficie atendiendo a la inclination de 
esta con respecto a la fuente de luz. Este 
sistema -conocido ya por la mayoria de 
los lectores- permite a los disenadores 
3d crear objetos de apariencia suavizada 
y realista empleando pocos poligonos. 
El sombreado Phong requiere un tierapo 
de calculo muy superior al llamado flat, 
donde solo se calcula un unico color pa- 
ra todos los puntos de un mismo polfgo- 
no, pero tambien es mucho mas real. 

Como ya vimos en el numero ante- 
rior, podemos ordenar diferentes tipos 
de sombreado desde la ventana de sub- 
proyectos. De esta manera todos los 
objetos se veran con una apariencia fa- 
cetada (con "Color shaded") o bien 
suavizada (con "Scanline" o "Trace"). 
Lo normal es exigir el modo de maxi- 
ma calidad ("Trace"). 

Comentamos todo esto porque hay 
un problema que se presentara con fre- 
cuencia en Imagine aunque ordenemos 
la maxima calidad. Existen objetos cu- 
yas superficies son total o parcialmente 
planas. En estos casos el programa ten- 
dra que realizar un sombreado liso o 
suavizado segun sea el caso. Algunos 
programas toman nota de cuando deben 
aplicar el suavizado o no realizando cal- 
culos de angulos entre polfgonos (si el 
angulo es menor de X, se efectua el sua- 
vizado). Pues bien, Imagine no es uno 
de ellos. Imagine aplica siempre, por 
defecto, un sombreado suavizado en to- 



das las caras y ello puede hacernos que- 
dar perplejos al observar el acabado fi- 
nal de muchos objetos (como cubos) que 
sabemos de superficie lisa. No obstante; 
ya hemos visto escenas de Imagine con 
objetos que tienen zonas lisas y zonas re- 
dondeadas. Sin ir mas lejos, la cabeza de 
Ray (el muneco pequeno de las gafas de 
los numeros 4 y 5) presenta zonas de las 
dos clases. ^Como se hizo esto? 

Veamos; ante todo hay que indicar a 
Imagine que partes del objeto deberan 
mostrarse alisadas y cuales redondeadas. 
En primer lugar, desde el Editor de De- 




Momento de la seleccion de 
bordes para el suavizado. 




La ventana de tipos de 
aplicacion de bitmaps. 



talles, seleccionaremos el objeto a tra- 
tar pinchando sobre el (en el modo de 
objetos o en el de grupos). Una vez se- 
leccionado este cambiaremos al modo 
"Pick Edges", en el submenu "Mode". 
Al hacerlo observaremos como los ver- 
tices del objeto quedan recuadrados en 
amarillo. Entonces -desde la ventana 
apropiada- dibujaremos una caja de se- 
lection ("Drag Box" en el apartado 
"Pick Method" del submenu "Mode") 
mientras mantenemos pulsada la tecla 
de Shift (modo multiple). Los puntos 
contenidos por la caja quedaran selec- 
cionados y podremos anadir nuevos 
puntos a esta seleccion usando nuevas 
cajas. Hecho esto iremos al submenu 
"Fuctions" y pincharemos en "Make". 
Aparecera otra ventana de la que desta- 
caremos dos opciones; "Make sharp ed- 
ges" y "Make soft edges". Si escogemos 
la primera, las caras implicadas presen- 
taran una apariencia lisa. Si escogemos 
la segunda, la apariencia sera suavizada. 
Normalmente, como por defecto toda la 
superficie de los objetos esta suavizada, 
escogeremos la primera option. 

Ir seleccionando puntos aunque sea 
usando una caja de arrastre puede ser 
engorroso, sobre todo si el objeto es 
complejo, y por ello Imagine dispone de 
un segundo metodo para efectuar estas 
selecciones. En el submenu "Pick/Se- 
lect" hay una option llamada "Edge Fil- 
ter" (Filtro de aristas). Al pinchar sobre 
ella aparecera una ventana mediante la 



Rendermam'a 3 






C oiiio... 




En la imagen se aprecia en detalle 
la aplicacion de un bitmap. 

cual podremos ordenar una selection de 
aristas -que cumpla ciertas condiciones- 
en el objeto o grupo seleccionado. Las 
condiciones mas importantes son el an- 
gulo mfnimo y maximo entre los que 
debe estar comprendida la arista. Apar- 
te de esto podemos ordenar que la se- 
lection se lleve a cabo solo entre las 
aristas lisas ("Sharp edges only") o entre 
las suavizadas ("Soft edges only"). En 
cuanto pulsemos sobre el boton de acep- 
tacion, Imagine tomara nota del modo 
en que deberan visualizarse las aristas 
en el proceso de Render. 

El gestor de atributos 

Como ya comentamos en el numero 
anterior, para crear los atributos (carac- 
terfsticas de superficie) de un objeto o 
modelo seleccionaremos el Editor de 
Detalles (desde el modo de objetos o 
grupos, segun sea el caso), y pulsaremos 
sobre "Attributes Requester", en el sub- 
menu "Functions". Entonces aparecera 
la ventana del Gestor de Atributos don- 
de se hallan los botones para dar color, 
transparencia (filter), rugosidad (rough- 
ness) y otras caracterfsticas a los obje- 
tos. En el numero anterior ya realizamos 
una breve description de la funcion de 
estos botones y no vamos a entrar ahora 
en mas detalles, ya que lo mejor es que 
el lector experimente con ellos. 

Los atributos de superficie asf crea- 
dos se guardan automaticamente con 
los objetos, cuando estos se graban. 



4 Rendermania 









I 


I °;~: KS52! 23m» 1 1 


— 







El gestor de las fuentes de luz es 
vital para lograr un buen efecto. 

Aparte de esto Imagine nos permite 
crear librerfas de atributos separada- 
mente, empleando los botones "Load" 
y "Save". (Normalmente guardaremos 
estas librerfas en el directorio Attribs). 

Aplicacion de bitmaps 

Tambien es en el Gestor de Atributos 
desde donde se realiza la aplicacion de 
las texturas. Imagine contempla dos ti- 
pos de ellas. Por un lado estan las textu- 
ras tipo bitmap (a las que Imagine llama 
"Brush") y por otro estan las llamadas 
texturas procedurales, las cuales se ge- 
neran siguiendo procedimientos algorft- 
micos. Hoy nos centraremos en la apli- 
cacion de bitmaps o mapas de imagen. 

Una vez seleccionado un objeto, y 
ya en la ventana del Gestor de Atribu- 
tos, veremos que el recuadro mas gran- 
de dentro de dicha ventana es el que se 
halla bajo el texto "Textures/Brushes". 
En este recuadro figurara la relation de 
texturas de uno u otro tipo que se va- 
yan a aplicar sobre el objeto (si las 
hay). Bajo el recuadro hay cuatro bo- 
tones relacionados con la aplicacion de 
texturas. Por el momento solo nos in- 
teresa el de aplicacion de bitmaps 
("Add Brsh"). Al pinchar sobre este bo- 
ton aparecera una nueva ventana que 
nos servira -buscando entre los direc- 
tories, si es preciso- para elegir el bit- 
map adecuado. Entonces. si escogemos 
un fichero. aparecera otra ventana des- 
de la que controlarei 





Detalle del gestor de 
transformaciones para los ejes. 

de la textura. Veamos lo que hacen al- 
gunos de sus botones: "Color" es la 
forma de aplicacion por defecto y en 
ella el color de cada punto del bitmap 
reemplaza al propio color del objeto. 
"Filter" utiliza la escala de grises del 
bitmap para dar diversos grados de 
transparencia al objeto sobre el que se 
aplica la imagen. (Las areas negras son 
opacas, las blancas transparentes y las 
grises translucidas). En cuanto al boton 
"Altitude", emplea el bitmap para si- 
mular irregularidades (bumpings) en la 
superficie del objeto. Esta option no pro- 
duce cambios en la geometrfa sino que 
emplea la information de color del bit- 
map para producir apariencias de abul- 
tamientos o depresiones en el objeto. 

Otros botones importantes son "Flat 
X", "Wrap X", "Flat Z" y "Wrap Z". 
Con ellos especificaremos el tipo de pro- 
yeccion que efectuara el bitmap sobre el 
objeto, debiendo escoger entre uno u 
otro tipo segun la forma de^bieto. En 
la porlada del numero anterior viraos un 
eiemplmkaiMMaction plarir^^^j^ 



ella teniamos un bitmap que querfamos 
aplicar sobre un objeto de forma alisa- 
da para simular una rcvista. En la pro- 
ycccion plana, los puntos del bitmap se 
aplican pcrpendicularmente al piano 
formado por la superficie del objeto (en 
este caso la revista) a fin de cvitar dis- 
torsioncs visuales. Estas distorsiones 
son visibles como "estiramientos" del 
iitmap en las zonas del objeto donde la 



II 




Modo flat. 




superficie deja de ser perpendicular al 
eje de aplicacion. De hecho, si uno de 
los poh'gonos del objeto queda paralelo 
al eje de aplicacion, veremos que cada 
punto del bitmap se estira indefinida- 
mente para cubrir cada punto de la su- 
perficie del mismo. Para comprender 
esto imaginemos un cubo sobre el que 
realizamos una aplicacion plana per- 
pendicular a una de sus ca- 
ras. La aplicacion resultara 
perfecta en dicha cara y tam- 
bien en la otra cara paralela 
del cubo pero en las otras, en 
cambio, apreciaremos el feo 
efecto de estiramiento. Esto 
se debe a que en la aplicacion 
plana del bitmap, cada pixel 
del mismo atraviesa espacial- 
mente al objeto en la direc- 
tion del eje de aplicacion y se 
deposita en cada punto de la 
superficie, al entrar en el ob- 
jeto o salir de el. Para evitar 
este efecto hay dos sistemas; 
uno cambiar la orientation del 
eje de aplicacion de modo que 
no sea paralelo a ninguna de 
las caras del objeto (lo cual es 
una chapuza) y otro es cam- 
biar el propio objeto. Esto ulti- 
mo fuekMjue^e hizo en la 
portada del niimero anterior, donde el bit- 
aplico solo en un piano puesto en- 
cima del objeto que hacfa las voces de re- 
vista. El modo de aplicacion piano es el 
empleado por defecto por Imagine. 
En la aplicacion esferica, en cambio. 
bitmap se cnrolla alrededor del obje 
siguiendo la forma del mismo. Usa- 
os los 4 botones antes mencionados 
tches cuando deseemos reali- 
zar una aplicacion que resulte plana en 
un eje y esferica en otro. (Para un cubo 

M HP 



marcariamos "Flat X" y "Flat Y". Para 
un cilindro marcariamos Wrap en un 
eje y Flat en otro y para una esfera mar- 
cariamos Wrap en los dos). 

Otros boton de la ventana con gran 
importancia es "Edit Axes", con el cual 
podremos controlar directamente la 
aplicacion del bitmap. Supongamos que 
hemos elegido el modo flat. Al pulsar 




retornaremos a la ventana de aplica- 
cion, donde pulsaremos sobre "Ok". 
Entonces volveremos a la ventana ante- 
rior donde veremos como el nombre del 
bitmap se ha incluido en el recuadro 
"Textures/Brushes". 

Para eliminar este bitmap o cambiar 
la aplicacion del mismo sobre el objeto 
pincharemos sobre "Info", lo cual nos 
hara entrar nuevamente en la 
ventana de aplicacion desde 
la cual podremos Uevar a ca- 
bo la modification o bien 
eliminar la aplicacion pin- 
chando en el boton "Drop". 



Acabado suavizado 




Anadiendo texturas. 



Anadiendo sombras. 



sobre "Edit Axes" veremos como se vi- 
sualiza un piano (en una de las venta- 
nas) sobre el objeto en ha de efectuarse 
la aplicacion. Este piano nos esta indi- 
cando la zona donde va a aplicarse el 
bitmap y su orientation y escala con 
respecto al objeto. Podremos alterares- 
tas caractensticas usando los conocidos 
Ujotones de escalation, rotation y des- 
^^amiento de la fila inferior de boto- 
nes. Mna vez que quedemos contentos 
con la aplicacion. pulsaremos espacio y 





Sombras 

Para que los objetos arrojen 
sombras habremos de activar 
el flag "Cast Shadows" en la 
ventana "Light Source Info". 
Para acceder a esta ventana 
tendremos que ir al Editor de 
Acciones, cuyo funciona- 
miento no vamos, por ahora, 
a explicar. Para nuestros fi- 
nes bastara con saber que es 
aqui donde podemos cam- 
biar las propiedades de la 
fuente de luz. Al entrar en el 
Editor veremos una pantalla 
de trabajo donde cada objeto 
tiene un nombre situado en alguno de 
los recuadros de la izquierda. Buscare- 
mos el nombre de la fuente de luz (nor- 
malmente "Lightsource") y pinchare- 
mos primero en el boton "Info", 
situado en la esquina inferior izquier- 
da, y luego en uno de los puntos de co- 
lor del cuadro situado a la derecha del 
nombre de la fuente. Entonces apare- 
cera la ventana "Light Source Info", 
donde marcaremos el recuadro antes 
mencionado. 



Rendermania 5 



Mr 



Ft 



Taller Virtual 



La atmosfera en POV 3.0 



nte todo conviene 

Aempezar repitiendo 
la advertencia del 
Povteam: la senten- 
cia "Atmosphere" 
es aiin experimental 
y existe una alta probabilidad de que 
sea modificada en una futura version 
de POV, de modo que se pierda la com- 
patibilidad con la instruction actual. 
De todos modos, teniendo en cuenta el 
interes intrinseco de esta sentencia, ne- 
mos decidido trastear con ella. 

El modelo atmosferico de POV 

Segiin el manual de POV: "la senten- 
cia atmosphere se emplea para reflejar 
la interaccion de la luz con las partfcu- 
las del aire". Con Atmosphere, las emi- 
siones de luz seran visibles y los objetos 
arrojaran sombras sobre la niebla o el 
polvo suspendido de la atmosfera. Esto 
es un paso adelante con respecto a la 
sentencia Fog, la cual no es sino una 
aproximacion bastante simple al feno- 
meno de la niebla (recordemos que Fog 
no interactua con la luz). Por supuesto, 
Atmosphere es tambien, como cualquier 
otro intento de simular los fenomenos 
del mundo real en un ordenador, una 
aproximacion. Pero produce resultados 
mas reales que Fog gracias al muestreo 
de volumenes espaciales que realiza su 
algoritmo para calcular la interaccion 
entre la luz y las parti'culas atmosfericas. 
El actual modelo atmosferico gene- 
rado con Atmosphere asume una den- 




6 Rendermania 



El cuarto sin atmosfera y 

la atmosfera con un valor 

bajo de muestreo 





sidad constante de particulas en el aire, 
exceptuando el volumen espacial de los 
objetos solidos. Si queremos crear nu- 
bes, humo u otras distribuciones irregu- 
lares de particulas deberemos recurrir a 
los halos. La sintaxis de la sentencia es: 
atmosphere { 
type NUMERO_DEL TIPO 
distance DISTANCIA 
[ scattering SCATTERING ] 
[ eccentricity ECCENTRICITY ] 
[ samples SAMPLES ] 
[jitter JITTER] 

[ aajhreshold AA_THRESHOLD ] 
[ aajevel AA_LEVEL ] 
[ colour <COLOUR> ] 

) 

La palabra "Type" se usa para indicar 
el tipo de modelo de dispersion lumino- 
sa que va a emplearse (o sea, como van 
a dispersar la luz las particulas de la at- 
mosfera). El modelo mas sencillo y ra- 
pido es el isotropico (el 1), en el cual la 
cantidad de luz dispersada no depende, 
como en los otros modelos, del angulo 
entre la direction de vision y el rayo de 
luz. El modelo isotropico es el que he- 
mos empleado en todos los ejemplos. 

La siguiente palabra, "Distance", es 
usada por POV para averiguar la densi- 
dad deseada de las particulas de la at- 
mosfera. Como antes se ha dicho, esta 
densidad sera constante para toda la at- 
mosfera. "Distance" funciona aqui' igual 
que para la niebla constante en la que, 
recordemos, cuando la distancia de un 
objeto iguala a la del valor dado a "Dis- 



tance", el color del objeto estara com- 
puesto por un 64% de color propio y 
por un 36% del color de la niebla. 

La palabra "Scattering" se usa para 
cambiar la cantidad de luz que es dis- 
persada por la atmosfera. De esta mane- 
ra controlaremos el brillo de la misma. 
Los valores pequenos disminuyen el bri- 
llo y los valores altos lo incrementan. La 
luz que no es dispersada, es absorbida. 

Con la palabra "Color" (o "Colour") 
podremos especificar un color para la 
atmosfera. El color puesto por defecto 
es el negro. En cuanto a la cantidad de 
luz que es filtrada por el color de la at- 
mosfera, depende del valor dado en el 
parametro filtro. Por ejemplo con "rgbf 
<1 ,0,0,0.40> ", el 40% de la luz sera fil- 
trada hacia el color de la atmosfera. Asf 
pues, un valor de .10 significa un tono 
muy tenue de rojo y un valor de .70 im- 
plica una atmosfera "marciana". Tam- 
bien podemos emplear "Transmittance" 
en vez de "filter" (o sea; "rgbt"). Trans- 
mittance, que funciona aqui igual que 
en Fog, se emplea para especificar el 
minimo de translucidez de la atmosfera. 

El algoritmo empleado por "Atmosp- 
here" funciona realizando muestreos 
del volumen espacial a lo largo del rayo 
de vision. En cada punto muestreado se 
tomara nota de si dicho punto cae den- 
tro de un rayo de luz o no. Si un punto 
muestreado cae dentro de una zona ilu- 
minada, la cantidad de luz dispersada 
en la direction del observador sera de- 
terminada y sumada a la intensidad to- 



Rendermania 7 



*>■*» 




Taller Virtual 




tal. El numero de estos muestreos sera 
determinado por la palabra "samples", 
que indicara el numero de muestreos 
que se efectuaran para cada intervalo 
en el rayo de vision. La longitud de cada 
intervalo sera o bien la distancia dada 
por "Distance" o bien la longitud hasta 
una parte iluminada por un rayo de luz. 
En cualquier caso lo que debemos re- 
cordar es que a mayor numero de mues- 
treos, mas reales seran los resultados. 

Otro punto a tener en cuenta es que, 
como el resultado final depende de una 
serie de testeos a lo largo de un volumen 
espacial, sera conveniente realizar un 
antialias en los resultados. Por supuesto, 
podemos limitarnos a dar un valor lo su- 
ficientemente alto a "samples", pero es- 
to seria parecido a generar siempre ima- 
genes a resoluciones muy altas (en 
cuanto a coste de tiempo). Otra solution 
viene dada por las palabras "Jitter", 
"aajevel" y "aajhreshold". 

Usando jitter, el punto espacial donde 
va a efectuarse el muestreo es desplaza- 
do una pequena distancia aleatoria a lo 
largo de la direction del rayo del obser- 
vador, lo cual ayuda a reducir el proble- 
ma del "escalonamiento". Un buen va- 
lor para jitter es 0.5. Valores mas altos 
pueden producir un exceso de "ruido" 
visual en los resultados. 

Otra posibilidad para evitar este pro- 
blema es efectuar un "super-muestreo" 
(super-sampling). Esta tecnica realiza 
muestreos adicionales en las zonas 
donde las intensidades entre dos puntos 



muestreados son muy diferentes. En ese 
caso se realizaran mas muestreos de for- 
ma recursiva hasta que se alcance el ni- 
vel de recursion indicado o hasta que las 
diferencias de intensidades entre los 
puntos muestreados queden dentro de lo 
tolerable. La palabra "aajevel" indica el 
nivel maximo de recursion y la palabra 
"aa_threshold", la diferencia maxima 
permitida entre la intensidad de dos mues- 
treos (a fin de dar por acabado el proceso). 

Los ejemplos de POV 

En el directorio docsdemo de POV 
se incluyen varios ficheros de ejemplo 
cuyo nombre empieza por atmos para 
ilustrar el uso de "atmosphere". En to- 
dos ellos (salvo en el ultimo) se mues- 
tra una habitacion iluminada con una 
fuente puntual. La habitacion consta de 
una ventana por la que entra la luz de 
una fuente spotlight, que ilumina el 
suelo. En el primer ejemplo, atmos 1, 
no hay atmosfera de ninguna clase. En 
el siguiente caso, atmos2, se anade la 
atmosfera pero el resultado, un efecto 
de escalonamiento luminoso, no es 
muy bueno. En el tercer ejemplo hay 
algunas mejoras que dan un resultado 
mas vistoso. La primera mejora consis- 
te en un valor de muestreo bastante ma- 
yor. Ademas, se anade un porcentaje de 
"jitter" y se anade el supersampleado. 

Cuestiones a tener en cuenta 

Cuando usemos "Atmosphere" debe- 
mos aseguramos de que todos los objetos 



que deban tener atmosfera sean declara- 
dos como huecos con hollow. Esto tendre- 
mos que hacerlo incluso con la primitiva 
"plane", tal como sucedfa con los halos. 

De igual manera, "Atmosphere" no 
funcionara si la camara no esta coloca- 
da en un objeto hollow. 

Cuando, despues de realizar una se- 
rie de pruebas, deseemos lanzar una 
imagen definitiva a mayor resolution, 
tendremos que aumentar el numero de 
muestreos. De lo contrario apreciaremos 
efectos de escalonamiento que no resul- 
taban visibles a resoluciones inferiores. 
Por defecto, las fuentes de luz interac- 
hian siempre con la atmosfera. Si en al- 
gun caso deseamos evitar esto bastard 
con afiadir la palabra "atmosphere off' 
en la declaracion de la fuente. Esto es lo 
que hemos hecho con la fuente puntual 
azul de la escena de la malla tridimen- 
sional. La otra fuente de luz es una "Spo- 
tlight" corriente con "Atmospheric_atte- 
nuation on" (en la escena de la malla 3d 
se ha sustifuido la antigua niebla que se 
puso en el numero 2, por una sentencia 
"atmosphere"; este experimento, no de- 
masiado Iogrado, fue el primero realiza- 
do por el autor con esta sentencia). 

Normalmente los rayos de una fuen- 
te no se debilitan -en POV- al atravesar 
la niebla o la atmosfera. Si deseamos 
cambiar este comportamiento usaremos 
la palabra "Atmospheric attenuation" 
dentro de la declaracion de la fuente. 
Este atenuamiento solo funcionara si la 
escena tiene atmosfera o niebla. 



8 Rendermam'a 



I 



I i V I 




t m 



Codigo & Pixels 



Programacion de un 
desastre a escala global 



Quienes dominan la filosofia de POV 
saben que las caracteristicas de su 
lenguaje escenico -sobre todo las de sus 
sentencias "de programacion"- permiten 
la creacion de escenas que resultarian 



sumamente dificiles con otros 
programas. Esto es algo que ya nemos 
comprobado en diversos numeros de 
Rendermania, pero aun no puede decirs 
que hayamos explorado todas las 
posibilidades de la "pov-programacion" 



como herramienta de diseno infografi 
cExisten las funciones de usuario en 
POV? iQue es la recursion? <,C6mo 4 

pueden emplearse las sentencias de POV 
para crear edificios en ruinas? 







Rendermania 9 






Codigo & Pixels 




n edificio en ruinas 
o -peor aiin- una ciu- 
dad en ruinas viene 
a ser el tfpico ejem- 
plo de proyecto que 
resulta muy facil de 
realizar con POV pero bastante diffcil de 
acometer con otros programas como 
Imagine o 3D Studio. La razon es, por 
supuesto, que en el disefio de un proyec- 
to de este tipo intervienen factores repe- 
titivos o patrones que son facilmente re- 
presentables si disponemos de un 
lenguaje escenico (como el de POV). 
Con un lenguaje podremos crear bucles, 
cambios en el disefio basico dependien- 
do de ciertas condiciones, y otras cosas. 
Hay que tener en cuenta que un edificio 
corriente (en ruinas o no) equivale a un 
monton de objetos simples que se repi- 
ten una y otra vez tales como vigas, 
plantas, columnas, etc. Con POV pode- 
mos emplar las sentencias de bucles pa- 
ra, con unas cuantas li'neas, crear un edi- 
ficio de este tipo. Tambien podemos 
emplear las sentencias de azar para in- 
troducir pequefias irregularidades en el 
tamano o en la composition de los mo- 
delos y -por ultimo- podemos emplear 
nuevamente las sentencias iterativas pa- 
ra componer una matriz de edificios, 
creando asi una ciudad. Con POV todo 





esto puede ser posible con un corto fi- 
chero de texto. ^Os imaginais el trabajo 
que implicarfa el montaje de cada uno 
de estos elementos "a mano" con un 
modeladorde ventanas? 

Lo que pretendemos 

La idea de la que nacio el proyecto de 
la ciudad arrasada partio de las barraba- 
sadas a las que sometio Katsuhiro Oto- 
mo a Neo-Tokio en su ultrafamoso 
manga Akira. En dicho manga esta des- 
dichada ciudad es primero destrozada 
por una bomba nuclear, luego, ya re- 
construida, es vuelta a destrozar por 
Akira, despues es sometida a la guerra 
civil psiquica, mas tarde es bombardea- 
da por los americanos y, por ultimo, es 
vuelta a "ultradestrozar" por Akira. Ni 
que decir tiene que los fondos de las vi- 



netas de esta obra estan 
llenas de edificios destro- 
zados. El resultado grafi- 
co es espectacular pero, 
sin embargo, una de las 
cosas que mas saltaran a 
la vista de cualquier pov- 
adepto -sobre todo en las 
ultimas paginas- es que 
casi todo el efecto se lo- 
gra mezclando edificios 
que -aunque muy detalla- 
dos a veces- son muy faciles de repro- 
ducir con POV. Esto se debe a que los 
edificios futuristas dibujados por Oto- 
mo estan creados con muy pocos ele- 
mentos diferentes. Estos elementos, en 
cada edificio, estan desalineados, rotos 
y retorcidos pero son, en definitiva, de 
muy pocos clases distintas y de formas 
muy sencillas. Para comprobar esto 
crearemos primero un edificio sencillo 
y luego lo destrozaremos. 

Aqui no hay calles (ni playa) 

Bueno, realmente si habia algo en 
Akira que era de muy diffcil representa- 
cion; las montanas de escombros que 
llenaban las calles. Ciertamente habria- 
mos podido representar estos escombros 
de varias formas distintas, pero la unica 
manera convincente hubiera sido apilar 




10 Rendermama 




cientos de pequenos objetos de formas 
variadas. Ademas tendnamos que haber 
representando las irregularidades de las 
calles; el suelo levantado, las aceras, las 
farolas, etc. Y ademas, habria que haber 
preparado tambien las entradas de los 
edificios, lo cual hubiera sido, sin duda, 
la parte mas dificil del disefio. 

Aquf hemos solucionado el proble- 
ma a la manera gordiana clasica: supri- 
miendolo. Esto se ha hecho cambian- 
do el tipo de desastre que en nuestras 
paginas ha pasado a ser un recalenta- 
miento de la temperatura mundial glo- 
bal, lo cual ha producido el deshielo de 
los casquetes polares acompafiado de 
la consiguiente subida del nivel del 
mar. De esta manera, al suponerse que 
los edificios estan parcialmente sumer- 
gidos, nos hemos ahorrado todo los 
problemas antes descritos. 

Ano 2034 

La verdad es que puede decirse que^ 
nuestros edificios perter 
cas diferentes. En la primera la catastro 
fe es aiin niiiy reciente y los edificios es- 
tan practicamente intactos. en la 
segunda el tiempo ha pasado y los edifi- 
cios muestran senales de erosion, y en 
la tercera ha pasado aiin mas tiempo 
-quiza siglos- y los edificios estan a 
punto de derrumbarse. Para representar 
la primera epoca usaremos el fichero 
edifiO.pvm del que eliminaremos las 




sentencias rand. Ademas sustituiremos 
las texturas bitmap en el fichero pov por 
colores pianos. Para la segunda epoca 
emplearemos el mismo fichero .pvm, 
sin cambios, y sin sustituir las texturas 
en el fichero pov. Finalmente, para la 
tercera epoca, emplearemos el archivo 
edifi 1 .pvm. (A partir de ahora citaremos 
un ano para referirnos a los edificios de 
cada epoca; 2034 para los edificios de la 
primera epoca, 2056 para los de la se- 
gunda y 21 10 para los de la tercera). 

Para los edificios de cada epoca el 
modo de construccion es casi el mismo. 
Cada edificio esta compuesto por 4 fa- 
chadas, los techos de cada piso, el tejado 
y su barandilla y las columnas laterales. 
Cada fachada, a su vez, esta compuesta 
por tres elementos; los bloques horizon- 
tales, los verticales y los cristales (si los 
hay) de las ventanas. Todos nuestros 
edificios se construyen empleando el 
mismo a lgoritmo de construccio n, en el 
suministra al fichero "macro" el 
lero depisos (npisos) y el numcro dc 
ventanas (nventanas). Otros parametros 
sei viran para determinar la forma del 
edificio. Con las variables "npisos" y 
Siventanas" el algoritmo del fichero 
.pvm empleado eonstruye 4 fachadas cu- 
yo tamano puede determinarse asf 

ancho=nventanas*4 



alto=npisos*5 

suponiendose que cada unidad equi- 
vale a un metro. 



Examinando los ficheros el lector no- 
tara que en cada edificio las fachadas 
podrian haberse construido empleando 
unas pocas vigas verticales cuya altura 
fuese igual a npisos*5. Tambien podria- 
mos haber procedido de manera similar 
con las vigas horizontales. Pero, en lu- 
gar de esto, hemos empleado muchas 
vigas mas pequeiias de tal forma que 
tendremos que, para cada fachada 
numero_de_vigas_verticales=npisos*nventanas 

siendo cada viga vertical de 5 metres 
de altura. 

Y lo propio sucede con las vigas ho- 
rizontales. Quiza el lector se sienta algo 
perplejo al considerar que podrfamos 
haber logrado el mismo resultado gra- 
fico con muchas menos vigas de mayor 
longitud. Esto es cierto pero solamente 
para los edificios del 2034. Para los 
posteriores nos resultara mas conve- 
niente el formato empleado. 

Aiio 2056 

Los edificios del 2034 estan practi- 
camente nuevos y resultan decepcio- 
nantes puesto que son excesivamente 
sencillos. Colocados en gran niimero a 
cierta disiancia de la camara podrian. 
quiza. cumplir su papel pero hay que 
recordar que no tienen puertas, rii ador- 
nos de ninguna clase y ademas resul- 
ente parecidos y unifor- 




Los del ano 2056, en cambio, ofre- 






Codigo & Pixels 



cen un resultado grafico mas atractivo 
precisamente porque estan mas trabaja- 
dos por el tiempo. Para empezar hemos 
aplicado una textura creada con Photos- 
hop en la que -aparte de ciertas rugosi- 
dades debidas a la erosion- se aprecian 
grietas y roturas varias. El siguiente pa- 
so ha sido aplicar un efecto aleatorio 
comprendido entre y 12 grados a la 
orientation de cada una de las piezas- 
viga que componen las fachadas. Tam- 
bien hemos hecho que el sentido del gi- 
ro para cada pieza dependa de un factor 
aleatorio. Esto se logra con las h'neas 

#declare a=rand(semilla) 

#if(a<.50)#declarea=l 

#else#declarea=-l 

#end 

Como recordareis, la funcion rand de 
POV devuelve un resultado flotante ale- 
atorio entre y 1 empleando la semilla 
inicializada con la funcion seed. Por tan- 
to las probabilidades de obtener un valor 
I para la variable "a" son del 50%. En 
las h'neas siguientes empleamos "a" pa- 
ra determinar el sentido del giro en cada 
pieza vertical asf, la linea siguiente 

object) viga_v rotate x*(rand(semilla)* 1 2)*a} 

crea una viga vertical a la se que rota 
una cantidad aleatoria de grados (com- 
prendida entre y 12) en el eje X. El 
giro se efectuara en un sentido o en 
otro dependiendo del valor de "a". Este 
truco tambien se emplea con las piezas 
horizontales y con las columnas latera- 
les del edificio cuando las hay. 

Alio 2110 

Aunque el listado es casi el mismo, 
los edificios del 2056 parecen mas con- 
seguidos que los del 2034. Sin embargo 
aiin no podemos ejecutar la danza de la 
victoria ya que el acabado "catastrofi- 
co" del 2056 aun no es perfecto. Como 



sabemos, en los edificios lo suficiente- 
mente "arruinados" suele haber aguje- 
ros y roturas que se aprecian en zonas 
aleatorias de los mismos. Para conse- 
guirlas habfa que realizar restas espa- 
ciales (differences) entre el volumen de 
cada edificio y otros objetos. Ahora 
bien, ^que tipo de objetos se pueden 
emplear para efectuar dichas restas? La 
primera idea fue usar una union de es- 




feras escaladas y situadas aleatoriamen- 
te dentro de un espacio cubico. Quiza 
esto habria funcionado pero, temiendo 
que los recortes espaciales dejaran a los 
edificios con la apariencia de quesos de 
gruyere, se opto finalmente por emplear 
Heightfields. Estos objetos -como re- 
cordara el lector- se usan normalmente 
para crear mallas de apariencia monta- 



fiosa y su aspecto irregular resultaba, 
pues, ideal para los recortes espaciales 
que se deseaban. 

Asf pues se creo una union de 
heightfields para efectuar las restas en 
cada edificio. Cada heightfiel fue pri- 
mero rotado para que los picos de las 
montanas apuntaran en la direction co- 
rrecta. Hay un heightfield de recorte 
para cada fachada y tambien se emplea 
un quinto objeto de este tipo para efec- 
tuar recortes en el tejado. Los height- 
fields fueron escalados hasta alcanzar 
las dimensiones apropiadas y se usaron 
funciones rand en una serie de opera- 
ciones; algunas para introducir un valor 
de azar en la escala del heightfield en el 
eje de recorte, otras para randomizar la 
position del objeto dentro de dicho eje 
y otras para rotarlo alrededor del eje de 
recorte. La finalidad de estas operacio- 
nes es, desde luego, procurar que cada 
edificio tenga un recorte espacial dife- 
rente al de los demas. 

En cuanto a los bitmaps empleados 
para crear los heightfields, fueron ge- 
nerados segun un procedimiento des- 
crito brevemente en el Rendermanfa 
nurnero 1 ; creando primero los bitmaps 
de alzado con el propio POV y luego 
empleando dichos bitmaps para crear 
los objetos 3d. (Podeis ver un ejemplo 
adecuado de generation de un bitmap 
valido en imagen.pov). Las resolucio- 
nes de estos bitmaps son de 128*128 y 
64*64. (En caso de que vayamos a 
crear escenas con muchos edificios, es- 
ta resolution debe ser tan baja como 
sea posible para ahorrar memoria). 
Tambien se ha prescindido de la pala- 
bra smooth, ya que el suavizado del ob- 
jeto de recorte no era necesario y evi- 
tandolo podfamos ahorrar un poco mas 
de memoria. 



12 Rendermama 





Finalmente -y para ahondar aiin mas 
en el aspecto ruinoso de nuestros edifi- 
cios- podemos incluir un leve valor alea- 
torio de inclination a cada edificio. 

cMacros o funciones? 

En cuanto a la estructura de los fi- 
cheros de generation, en esta ocasi6n 
hemos empleado lo que algunos usua- 
rios de POV han dado en llamar "fun- 
ciones de usuario de POV". ^Que ocu- 
rre con estas "funciones"? Algunos 
usuarios -entre ellos vuestro seguro 
servidor- afirmaban que POV no las 
implementa mientras que otros asegu- 
raban fervientemente que si. Ademas 
en el numero anterior, en el foro del 
lector, el grupo Mithrandor envio una 
carta tratando este particular. Despues 
de leer dicha carta el autor de estas If- 
neas se inclino a dar la razon a los 
"funcionalistas" si bien, una vez pasa- 
do el entusiasmo inicial, vuestro seguro 
servidor ha retomado nuevamente su 
opinion inicial, o sea, jno existen las 
funciones de usuario de POV! 

t,C6mo debe entenderse esto? Cuan- 
do se habla de funciones de usuario de 
POV se esta dando a entender que di- 
chas funciones son similares en cuanto 
a su funcionamiento a las funciones de 
C. (De hecho el autor de estas lfneas re- 
cuerda vagamente haber lefdo algun 
faq al respecto hace ya algun tiempo). 
Las funciones de C, como saben los 
programadores, son bloques de codigo 
que, generalmente, realizan tareas con- 
cretas cuyos objetivos puede variar de- 
pendiendo de los parametros que se les 
pasen. Una vez compilado el progra- 
ma, el codigo correspondiente a una 
funcion dada solamente se almacena 
una vez en memoria debiendo encar- 
garse el programa de efectuar una 11a- 




mada a la position adecuada para que 
la funcion lleve a cabo su labor. Esta 
ultima condition es precisamente la 
que no cumplen las funciones de usua- 
rio de POV. 

Veamos lo que sucede con la "fun- 
cion de usuario" incluida en edifil .pvm: 

1 ) POV esta efectuando el "parsing" 
(compilation) de alguno de los fiche- 
ros .pov que llaman a edifil. pvm. La 
"funcion" de edifi 1 .pvm creara un edi- 
ficio cuyas dimensiones y forma de- 
penderan de los valores que se pasen en 
los "parametros" nventanas, npisos, la- 
teral, window, vigav y vigah. Despues 
de dar un valor a cada parametro preci- 
so, la siguiente lfnea del fichero .pov 
sera #include "edifi 1 .pvm". 

2) Cuando el parser (la parte de POV 



encargada del parsing, o sea de conver- 
tir en "codigo 3d" los ficheros esceni- 
cos) llega a la lfnea del include, lo que 
sucede es, sencillamente, que se actua 
como si todo el fichero edifi 1 .pvm es- 
tuviera escrito -a partir del include- en 
el archivo .pov en curso. POV "inclu- 
ye" su texto lfnea a lfnea en el archivo 
.pov y cuando termina de parsear las 
lfneas de edifi 1 .pvm continiia con las 
del archivo .pov inicial. Cuando, mas 
adelante, en el mismo archivo, POV 
encuentre otra lfnea #include "edi- 
fil. pvm", el proceso se repctira, aun- 
que puede que los resultados visuales 
sean muy diferentes ya que, presunta- 
mente, los parametros para esta llama- 
da a la funcion seran diferentes a los 
de la primera llamada. 

Exteriormente podra parecernos que 
el funcionamiento de esta pov-funcion 
es similar al de las funciones de C pero, 
internamente, lo que sucede se parece 
mucho mas al proceso de expansion de 
una macro de, por ejemplo, lenguaje 
ensamblador. (Por eso aquf empleamos 
la extension pvm; pov-macro). Sin em- 
bargo, y precisiones aparte. el truco es 
de una gran utilidad ya que podremos 
ahorrarnos la escritura de muchas lf- 
neas y estructuraremos mejor nuestras 
escenas. El lector hallara ejemplos de 
todo esto en edificio.pov, ciudad.pov y 
portada.pov. 

Los distintos tipos basicos 
de edificios 

Las definiciones de los bloques basi- 
cos de los edificios se hallan en los fi- 
cheros pov, con lo que basta con cam- 
biar dichos bloques para crear nuevos 
tipos. Los tipos que hemos empleado 
se hallan definidos dentro del switch, 
en ciudad.pov. 



Rendermania 13 



■ta* 



F* 



La Portada 



Escenas desastrosas 



No hay duda de que, a pesar de que el 
fantasma de la guerra nuclear esta un tanto 
difuminado hoy dia, el genero catastrofista goza 
de buena salud. Multitud de autores se afanan 
en plasmar catastrofes de todo tipo, ya sea en 
letra impresa, en vihetas o en imagenes. Hoy 
nos sumaremos a esta ^corriente? proponiendo 
una catastrofe mundial a escala global (y virtual 
afortunadamente), en la que el recalentamiento 
del planeta ha conducido al deshielo de las masas 
polares. ^El resultado? Ciudades sumergidas y 
en ruinas como la que podeis ver en la portada. 



Los pormenores de la 
construction de los 
edificios de la porta- 
da ya han sido des- 
critos en "Progra- 
macion 3D". Ahora 
explicaremos el proceso por el cual la 
portada quedo tal como podeis verla. 

Problemas en la creacion 
del area catastrofica 

Algunas de las ideas citadas en "Pro- 
gramacion 3d" no han sido llevadas a 
cabo en nuestra portada. De hecho los 



edificios empleados en ella no son los 
mas desastrosos (y resultones) de que 
disponemos, sino otros mas sencillos. 
Los problemas han sido los de siempre: 
tiempo y, sobre todo, memoria. La es- 
cena de portada, por ejemplo, ha re- 
querido unos 44 Megabytes. Esta can- 
tidad, que parece excesiva ante la 
sencillez de los modelos, se explica por 
la existencia de los cientos de peque- 
fios objetos simples que componen ca- 
da edificio. Estos objetos simples, ro- 
tados levemente en distintos ejes, 
producen (o deberfan producir) una 




buena impresion de destrozo y de com- 
plejidad en cada modelo. En cuanto a 
la construction de la ciudad, se ha em- 
pleado un bucle doble muy similar al 
que en su dia se uso en las ciudades 
medievales (ya que el principio es el 



14 Rendermania 







mismo). Este bucle, en la portada, sir- 
vio para generar 6*6 edificios. Estos 
"ruinosos" modelos, salvo por los suelos 
de cada piso, carecen de partes internas 
pero aun asi -y asumiendo 2 vigas por 
cada ventana, la posible adicion de un 



cristal y una media de 10*6 ventanas 
por fachada- hay una media de medio 
miliar de piezas simples por edificio. 

Por otro lado, si en vez de los mode- 
los empleados hubieramos usado los 
edificios del 21 10, la situation aun hu- 



biera empeorado mas, ya que cada edi- 
ficio de esta epoca sufre recortes por 
parte de 5 heightfields.para aumentar la 
impresion de vejez. Ademas de esto, 
como siempre, mayor complejidad sig- 
nifica mayor lentitud en la generation 
de las pruebas. Quiza una posible solu- 
tion hubiera estado en el empleo de 
uno u otro tipo de edificio atendiendo a 
la distancia de estos con la camara. 

Otro problema de la portada es la poca 
variation entre los distintos tipos de edi- 
ficios. En la pov-macro switched.pvm so- 
lo se definen 5 variaciones entre todos los 
casos posibles pero lo peor es que los dis- 
tintos elementos simples usados para 
crear estas variaciones son demasiado pa- 
recidos entre si. (Por esta razon no nos 
hemos molestado en anadir mas casos). 
Las macros edifiO y edifil emplean ob- 
jetos declarados fuera (o sea en el fichero 
.pov de llamada) para preparar el monta- 
je de cada edificio. Esto resulta comodo 
pero poco agil. Por otro lado quiza esto 
no sea necesariamente malo; el hacer ti- 
pos de edificios diferenciados entre si 
probablemente daria como resultado que 
nos fijaramos aun mas en las repeticio- 
nes, a menos, claro esti, que escribiera- 
mos una libreria de edificios extensa. 
Esto no era lo que hoy se pretendia jya 
que de todas formas los edificios iban a 
acabar como un monton de ruinas! 

Un ultimo punto a tener en cuenta es 
el hecho de que estamos usando una 
unica semilla para decidir los factores 
aleatorios de todo; el numero de venta- 
nas y pisos, la forma de los edificios..., 



Rendermam'a 15 



I i I 




P*W 



La Portada 



etc. Esto significa que no 
podremos predecir el resul- 
tado visual final salvo de 
una manera muy aproxi- 
mada. Claro que, por otro 
lado esto tambien tiene su 
atractivo, ya que bastara 
con cambiar el valor del pa- 
rametro de seed para obte- 
ner una ciudad distinta. 

En portada. pov nemos 
utilizado el sistema del do- 
ble bucle con factores aleatorios para 
crear una malla de edificios. Despues 
hemos colocado "a mano" un edificio 
de 22 pisos de altura y en el al monstruo. 
Puede suceder que un valor dado para 
seed de como resultado unos edificios 
excepcionalmente altos en las filas mas 
cercanas, con lo que no veremos nada 
mas alia de ellos. Tambien puede ocu- 
rrir que obtengamos una ciudad adecua- 
da salvo por un detalle que no podremos 
cambiar ya que nuestro unico control 
sobre el resultado sera pedirle al progra- 
ma que genere otra ciudad aleatoria. 

La portada 

Como antes se dijo, hemos incluido 
el mar para no tener que preocuparnos 
por los escombros, las calles, los coches. 
etc. Otra posible solucion hubiera sido 
semienterrar la ciudad entre las dunas de 
un desierto. Esto, sin embargo, haria que 
fuese bastante mas diffcil predecir la vi- 
sibilidad de cada edificio concrete 

Aparte de esto se barajo la posibili- 
dad de poner la camara a ras del agua 
para enfocar algun edificio cercano en 
el que se viera a nuestro monstruo prac- 
ticando alpinismo, pero esta idea fue de- 
sechada ya que hubiera sido muy diffcil 
ofrecer asi un panorama global de la 
ciudad. Tambien estaba previsto (jAy!) 




emplear modelos de edificios del 2 1 1 a 
los que se inclinaran sobre su eje segiin 
un factor aleatorio y tambien se acaricio 
la idea de reescribir los edificios de mo- 
do que pudieran extenderse los pisos. 

El modelo de Imagine 

Estaba claro que habi'a que incluir al- 
gun modelo que diera una idea adecuada 
del tamano de los edificios. La eleccion 
estaba muy clara dado que en el ultimo 
numero de Rendermania se incluyo un 
robot. Ahora bien, ^como exportarlo a 
POV? Bien, en Rendermanfa numero 1 
tratamos el tema de la exportation de 
modelos para POV. Todo cuanto se dijo 
en aquel artfculo acerca la orientation de 
los ejes, el escalado de los modelos, etc. 
sigue siendo vigente. Pero, naturalmente, 
esto no nos servira de mucho si no dis- 
ponemos de alguna herramienta que 
"traduzca" el formato de Imagine a POV. 
El autor de estas h'neas no ha hallado aiin 
esta herramienta. Por esta razon el mons- 
truo creado con Imagine fue grabado en 
formato DXF. Hecho esto las alternati- 
vas son algo mas amplias ya que existen 
muchos programas que "entienden" este 
formato; Wcvt2pov puede, porejemplo, 
leer DXF y grabar ficheros pov. Y tam- 
bien podemos grabar en formato 3ds y 
convertir luego a pov con 3ds2pov. Es- 



peramos hallar algun buen 
conversor de objs de Ima- 
gine en un future 

POV 3.01 

Finalmente hay que rese- 
nar que todos los renders 
del presente numero -sal- 
vo las paginas dedicadas a 
Imagine- fueron hechos 
con POV 3.0 1 , una actuali- 
zation que corrige varios 
bugs de la anterior y que podeis encon- 
trar en la siguiente direction de internet: 
http://www.povray.org 
Ademas, esta nueva version permite 
extraer un doctorial en formato html y 
otro en modo texto, por si no nos hace 
gracia el modo de ayuda normal. Pode- 
mos extraer el fichero html y meterlo 
en un subdirectorio llamado html con 
la siguiente linea: 
Phe2html -ipovhelp.phe -ohtml\ 
index.htm -ppov 

Tambien podemos extraer el fichero 
ascii con: 

phe2txt -povhelp.phe 
El nuevo manual ha cambiado algu- 
nas explicaciones y anadido ejemplos. 
En cuanto a POV, parece haber mejo- 
rado su tratamiento de errores. jQue lo 
disfruteis! 

NOTAEVIPORTANTE 

Para hacer vuestras propias pruebas: 
Copiad los ficheros .pov, .inc y .pvm a un 
mismo directorio. Meted ahf tambien la 
textura texed.tga (la textura de las pare- 
des) y, si vais a emplear edifi 1 .pvm, meted 
tambien los ficheros image o cread los 
vuestras prapios. Tambien puede resultar 
necesario realizar ligeros cambios en los 
ficheros .pvm dependiendo de cual sea el 
fichero .pov tratado. 



16 Rendermania 



1 M 



*m 



r > 



El Foro del Lector 



Nota importante. Podeis remitirnos vuestros trabajos o consultas, bien por carta a la direction que 
figura en la segunda pdgina de Pcmanfa, o via e-mail a rendermania.pcmania@hobbypress.es 



Piezas para juegos y 
batallas virtuales 



Nuestro foro de hoy 
resultara especialmente 
interesante a todos los 
rendermaniacos por su 
diversidad. Incluye, entre 
otras cosas, una NbrerTa de 
piezas para crear juguetes 
Tente de modo virtual, 
unas cabezas 
extraterrestres modeladas 
con Metaballs, mas 
pov-piezas virtuales para la 
anunciada batalla entre 
orcos y humanos, etc, etc. 
Damas y caballeros, 
pasen, vean y 
asombrense. 




En el numero 4 de Rendermani'a publicamos el carro de vapor creado por 
Oscar Alvarez Diaz. Este vistosavehfculo inspirado en el mundo de War- 
hammer fue el unico modelo superviviente del disco enviado por su creador. 
Escarmentado por este desastre informatico, Oscar ha vuelto a enviarnos su 
trabajo adjuntando esta vez copias de seguridad ;lo cual ha sido una suerte ya 
que uno de los discos volvid a t'allar! (Rendermaniacos, tomad nota: Enviad 
copias de seguridad y procurad que los discos vayan bien protegidos en el en- 
vio). En fin, por fin podemos contar hoy con la 
famosa vagoneta de ataque Snotling (o algo pa- 
recido) que Oscar diseno para ayudar a los orcos 
en su batalla virtual contra los humanos. Dispo- 
nents ya de varios piezas asf que pronto podre- 
mos preparar alguna batallita, aunque si alguien 
se anima a preparar el altar de guerra Imperial o 
el canon de salvas. mejor. Enhorabuena por es- 
tas estupendas maquinas, Oscar. 




Rendermani'a 17 




El Foro del Lector 




Nasser Afkir Torres, miembro 
del grupo Njteam nos envi'a su ulti- 
ma creation, una griia basada en una 
pieza a escala. Puesto que Nasser pi- 
de una opinion dire que, desde lue- 
go, este trabajo representa un paso 
adelante (sobre todo en complejidad 
de modelado) con respecto al orde- 
nador que enviaste la ultima vez. Lo 
unico que no me ha convencido de- 
masiado ha sido el fondo, que no me 
parece a la altura del modelo. En 
cuanto a los Ipas de 3D Studio que 
pides para el CD-Rom si no se trata 
de versiones shareware o autoriza- 
das, no cuentes con ello. Respecto a 
lo que dices de los cuelgues de 3D 
Studio por falta de memoria, no me 
parece probable que sea este el moti- 
vo. (,Que version tienes? 





Antonio Jose 
Garcia Mora nos 

envi'a varias esce- 
nas con efectos 
atmosfericos y 
una utilidad para 
generar superfi- 
cies extruidas y 
de revolution. Tomo nota de tu sugerencia acerca de dedicar un 
articulo al sistema de iluminacion de POV. Tambien a mi me 
gustan'a que Marcos Fajardo se decidiera a pasar su trabajo a la 
ultima version de POV. Es una pena que sus efectos se hayan 
quedado en la version 2.2. En cuanto a lo que dices de los halos, 
aunque no tengo los ficheros origi- 
nales (ya que fuiste cambiando los 
valores), creo que es posible que el 
problema resida en el escalado del 
halo con respecto al objeto conte- 
nedor, aunque eso no parece expli- 
car la sombra. Por ultimo, en lo que 
respecta al uso de Lparser, no re- 
cuerdo como dar colores individua- 
tes (sin trastear en el fuente con un 
editor). Es posible que dentro de po- 
co veamos aquf algunas tecnicas para la generation 
de arboles, ya que parece haber bastante gente inte- 
resada en el tema. Y para acabar, no he podido por 
ahora echar un vistazo a tu Editor de Splines. Pero, 
aunque no pretendo desanimarte, sera diffcil que tu 
utilidad tenga mucha salida. A fin de cuentas este te- 
ma esta contemplado en Moray y otros programas. 



De inexcusable lectura es la interesanti'sima carta remitida por 
David I.ozano Lucas donde explica como empleo el Metareyes 
para construir las Super Cabezas Extraterrestres que podeis ver 
aquf. Estas cabezas fueron creadas por David primero en plastilina 
y luego... pero lo mejor sera que leais su carta en el Foro. David in- 
cluye tambien una animation que mezcla animates reales con un 
fondo de 3D Studio (y que yo no he conseguido ver bien). Enhora- 
buena por tu original y excelente trabajo. 




18 Rendermania 




Daniel Susin Acebo tambien ha decidido tomar pane 
en la anunciada batalla virtual entre orcos y humanos y 
contribuye con este magnifica pov-catapulta que pasa a 
t'ormar parte del bando orco. Daniel pide una crftica 
"constructiva" (jJa!) de sus imagenes. Bien ,,que pode- 
mos decir? La catapulta esta esplendidamente disefiada y montada, las texturas (a 
pesar de tus temores) quedan perfectamente y no encuentro ningun punto debil 
salvo en la bola de fuego que. por otro lado, no es facil de hacer. Quiza hubieras 
debido poner una piedra normal. Anotate un 10.5 sobre 10. En cuanto a lo que pre- 
guntas sobre exportacion de modelos de Imagine para POV. supongo que habras 
lefdo el resto del presente niimero. 











Jose Maria Tejeda Martin 














^^^^ 




^^^^H ^SH 




-Dark int'ografica- es otro in- 










■*•— ■ ^^^ ^ 




fografista elaramente inspira- 










JH *-^gff ^^b 




do en el ejemplo de Tomwo- 
of y sus mangababes. Jose Man 
para 3D Studio al que llama Ch 
ver con el personaje de Street Fi 


a ha creado un modelo femenino 
unli (pero que no tiene nada que 
filter que pega palizas al autor de 






■■-' IH^S^H^^^^^^IPkTS 






estas lineas los sabados por la 
mafiana). Este modelo. del 








Hh 


Ix'Jo^mB 






que podeis ver unos ejemplos 


^fl 




4Jjf»$ wH^^EBKBK$8m 




~^^~ t*J^I 


aqui, puede ser recibido por 










4'. -^S 


todo aquel que decida regis- 








^^ 


trarse (ved los detalles expli- 








A. ■ 


cados por Joee Maria en los 










ficheros del foro). Buena suer- 












te para ti y para los siguientes 












modelos de la libren'a Chunli. 













Rendermania 19 



AmA 



JrVL El Foro del Lector 




Zeni Tallo nos envfa desde Sabadell cuatro escenas magnfficas. En su 
carta -que Zeni no ha enviado como fichero- este autor declara que 
aun se considera un novato en el uso de POV y que desconoce el fun- 
cionamiento de las estructuras complejas del programa tales como 
Smooth Triangle (£?) En su carta Zeni solicita una critica constructi- 
va y pregunta por el grado de calidad de sus trabajos. Finalmente Ze- 
ni pregunta por que es tan difi'cil modelar formas organicas con POV; 
el robot femenino iba en principio para chica de carne y hueso. 
Bien, vayamos por partes: Amigo Zeni tus escenas son muy buenas, 
sobre todo en el aspecto del modelado, y me han gustado mucho. 
Sin embargo, has omitido el envi'o de los ficheros de generacion sin 
los cuales mi critica tiene que reducirse necesariamente a un breve 
comentario acerca de lo resultonas que son tus imagenes. De estas me gusto sobre todo la ciudady tambien me gusto mucho el androide 
femenino, aunque hubiera preferido verlo de cuerpo entero. Sin embargo, me veo obligado a senalarte que, al no haberme remitido los fi- 
cheros de generacion, no puedo asegurar publicamente que las imagenes sean tuyas. Si eres un lector reciente quiza no hayas leido mis rei- 
teradas explicaciones acerca del porque de todo esto. Quiero aprovechar la ocasion para pedir a todos que envieis alguna prueba de que las 
escenas son efectivamente vuestras. Asf, a partir de ahora: 1 ) No hace falta que envieis los archivos de generacion completos. Bastara con 
que, al renderizarlos, se creen escenas con elementos significativos de las imagenes enviadas. Estos archivos, en cualquier caso, no seran 
publicados si el autor asf lo declara. 2) Si se trata de escenas de 3D Studio, Imagine o de cualquier otro programa de tipo poligonal, se agra- 
decera una pequena explicacion acerca de los modelos o de cualquier otra cosa que pueda permitirnos confiar en la autorfa de las obras en- 
viadas. No es preciso que envieis las mallas si no deseais verlas publicadas. 3) Si es 
posible, enviad los discos por duplicado. 4) Si me entero de que alguien me "cuela" al- 
guna obra robada sere el primero en denunciar el hecho y poner pasquines hasta en el 
himalaya para que el culpable no escape al escarnio publico. 

Cambiando de tema, nadie usa manualmente Smooth Triangle, ya que es una pri- 
mitiva puesta ahf por los desarrolladores de POV para que sea usada por los programas 
de utilidad que convierten mallas de otros programas; para que sus modelos puedan 
generarse en POV, claro. En cuanto a lo de las formas organicas, no se trata de una fal- 
ta de conocimientos o de habilidad por tu parte, sino de un campo muy, muy dificil, in- 
cluso empleando los modeladores y las utilidades mas poderosas. 



"""\t 

X(,BO u h 
VBI. tCT 

r f- 



iuJ ULJ , . 

a, naaDH 



-II H Ci-CX 
GD +K:l 







Jorge Martin Cuervo se Neva hoy lamedallaalaoriginalidadpuestoquenosenvfa 
una coleccion de piezas de Tente disenadas conjuntamente con POV y 3D Studio. 
Con dichas piezas, Jorge ha montado los barcos de ju- 
guete que podemos ver aqui. (j !). Jorge tambien nos en- 
vfa un proyecto de cocina creado con 3D Studio y que ha 
quedado incompleto debido a otro de esos desastres in- 
formaticos. Jorge pide que enviemos opiniones sobre su 
trabajo asf que aprovechare para dar la mfa: La idea de la 
coleccion de piezas Tente me parece muy original y bien 
realizada pero... ^Se puede construir un Castillo con ello? 



20 Rendermania